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IPPD  -  The  Concurrent  Approach  To  Integrating  Ship  Design, 
Construction  And  Operation 

Mark  Cote,  (V),  Bath  Iron  Works;  Richard  DeVries,  (V),  Designers  and  Planners,  Inc.;  Lee  Duneclift, 
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Inc.,  Kevin  Prince,  (M),  Designers  and  Planners,  Inc.  and  Jorge  Ribeiro,  (V),  CONSUNAV-RIO 

ABSTRACT 

This  concept  of  concurrent  engineering  is  a  philosophy  widely  accepted  as  the  correct  approach  to 
considering  all  disciplines  in  the  course  of  a  design.  The  methods  that  are  used  to  solicit  and  incorporate 
the  input  are  not  so  widely  accepted.  Integrated  Product  and  Process  Development  (IPPD)  is  a  technique 
that  has  been  successfully  applied  to  the  Engine  Room  Arrangement  Modeling  (ERAM)  project. 

The  paper  addresses  the  experience  of  the  ERAM  team,  which  is  an  element  of  the  US  Navy  s  Mid-Term 
Sealift  Ship  Technology  Development  Program  and  will  focus  on  issues  that  may  be  experienced  in  a  US 
shipyard  environment  when  applying  IPPD.  The  IPPD  process  will  be  discussed  from  two  perspectives.  First 
the  team  formation,  training  and  operation  will  be  addressed.  The  team  issues  include  such  elements  as 
team  formation,  requirements  for  collocation,  project  pre-planning,  team  training,  team  member 
development,  integration  of  new  team  members,  maintaining  team  work  including  peer  review,  establishment 
of  norms  and  consensus  building.  In  general,  issues  differing  from  current  practices  will  be  addressed. 

Next,  the  application  of  the  approach  to  ship  design  while  considering  cradle  to  grave  costs  will  be 
addressed  from  a  technical  standpoint.  The  technical  approach  will  provide  a  general  outline  of  the  steps 
followed  in  developing  the  engine  room  arrangement  models,  using  the  IPPD  approach.  This  outline  reflects 
both  the  initial  development  and  the  evolution  over  several  engine  room  designs.  The  conclusion  of  the 
paper  will  define  what  steps  the  ERAM  team  recommends  US  shipbuilders  should  implement  in  adopting  the 
IPPD  process. 


NOMENCLATURE 

AutoCAD® 

AutoCAD  is  a  general  purpose  Computer-Aided 
Design/Drafting  design  package  for  computers. 

COMPUTER  AIDED  DESIGN  (CAD) 

Computer  aided  design  is  the  use  of  computers  to  aid 
system  engineers  and  designers  in  the  design  of  the  end  product. 

COMPUTER  AIDED  DESIGN/COMPUTER  AIDED 
MANUFACTURING  (CAD/CAM) 

The  process  of  creating  a  direct  link  between  the  design 
developed  on  the  computer  to  the  machine  manufacturing  the 
product. 

CONCURRENT  ENGINEERING  (CE) 

Concurrent  Engineering  is  a  systematic  approach  to  the 
integrated,  concuixent  design  of  products  and  their  related 
processes,  including  manufacturing  and  support.  This  approach 


drives  the  designers  to  consider  all  elements  of  the  product  life 
cycle  from  conception  through  eventual  disposal.  (1) 

INTEGRATED  PRODUCT  AND  PROCESS 
DEVELOPMENT  (IPPD) 

The  Integrated  Product/Process  Development  technique 
proposes  using  TEAM  involvement  and  TEAM  'ownership'  of 
the  development  process  for  a  given  product.  Fundamental 
concepts  underlying  this  technique  include  a  strong  emphasis  on 
customer  satisfaction  compared  to  the  more  conventional 
approaches,  and  the  use  of  multi-functional  teams.  The  TEAM 
is  guided  by  a  Steering  Committee  composed  of  upper  level 
management  who  are  ‘champions’  of  the  project.  (2) 

STRATEGIC  DESIGN  METHOD  (SDM) 

The  Strategic  Design  Method  is  based  on  the  concept  of 
IPPD,  with  the  multi-functional  members  of  a  design  team 
empowered  to  address  the  total  business  product  strategy. 
Using  SDM,  a  road  map  is  developed  to  provide  team  members 
with  a  route  through  the  Strategic  Design  Processes.  A  key 
element  of  SDM  is  that  metrics  are  used  to  access  the  direction 
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the  team  is  headed  and  adjust  the  focus  of  the  team’s  activities 
as  necessary.  Although  metrics  would  appear  to  be  a  simple 
process,  the  development  and  application  will  be  one  of  the 
team’s  biggest  challenges.  (3) 

QUALITY  FUNCTIONAL  DEPLOYMENT  (QFD) 

QFD  is  a  tool  for  formulating  strategic  plans  of  action  by 
consolidating  the  inputs  of  numerous  participants.  These 
participants,  or  stakeholders,  should  represent  a  broad  variety  of 
perspectives  on  the  subject  being  planned,  to  assure  that  all 
viewpoints  are  considered.  The  tool  provides  a  way  to  impose 
discipline  on  brainstorming  sessions  which  can  otherwise  tend 
to  lose  direction  and  focus.  (2) 

INTRODUCTION 

This  paper  describes  the  Integrated  Product/Process  Design 
(IPPD)  processes  developed  by  the  Engine  Room  Arrangement 
Modeling  (ERAM)  Team  under  a  project  initiated  by  NAVSEA 
under  the  Midterm  SEALIFT  Program.  The  objective  of  the 
project  was  to  identify  a  specific  set  of  design  processes,  using 
IPPD  technique,  which  would  lead  to  cost  and  schedule 
improvements  for  engine  room  design  and  construction  over 
traditional  shipyard  practices.  The  team  was  guided  by  a 
Steering  Committee  consisting  of  representatives  from 
academia,  three  shipyards,  two  ship  owners,  a  design  agent  and 
NAVSEA.  Guidance  was  provided  via  the  ‘ERAM 
Requirements  Document’  which  contained  the  following 
‘Vision  Statement’: 

A  customer-focused  process  that  enables  the  U.S. 
shipbuilding  industry  to  design  and  build  engine 
rooms  which  promote  internationally 

competitive  commercial  ships. 

This  vision  statement  was  accompanied  by  seven  (7)  objectives. 

1 .  Provide  a  forum  for  U.  S.  shipbuilders  to  present  views  and 
needs  for  product  and  process  design. 

2.  Within  12  months  develop  a  process  for  marine  industry 
use  to  design  internationally  competitive  commercials 
ships. 

3.  Within  24  months  demonstrate  the  process  by  designing 
four  (4)  world  class  engine  room  arrangements. 

4.  Achieve  customer-focus  and  buy-in  of  product  design  (4 
Engine  Room  Arrangements). 

5.  Achieve  U.  S.  shipbuilding  industry-focus  and  buy-in  of 
the  design  process. 

6.  Establish  baseline  commercial  ship  engine  room  designs 
for  evaluation  of  future  government  initiated  changes. 

7.  Document  both  the  product  and  process  design  with 
rationale  for  use  and  future  refinement  by  other  users. 

The  initial  set  of  design  processes  were  identified  during 
the  design  of  a  Sealift  ship  engine  room  fitted  with  a  slow-speed 
diesel  engine  power  plant.  These  processes  were  then  applied  to 
a  medium-speed  diesel  and  an  additional  slow  speed  diesel  plant 
design,  and  were  continuously  improved  as  the  project’s 
participants  gained  more  experience. 

To  arrive  at  the  recommended  design  processes,  a  course  of 


action  was  set  at  the  beginning  of  the  project  to  identify  baseline 
processes.  Careful  monitoring  was  continually  performed  to 
identify  both  positive  and  negative  aspects  of  these  baseline 
processes.  Based  on  the  lessons  learned  in  executing  each 
iteration,  the  processes  were  refined. 

The  lessons  learned  include  lessons  related  to  IPPD,  SDM, 
and  QFD  techniques  which  were  applied  throughout  this 
project.  The  resulting  refinements  were  based  on  careful 
observation  of  which  aspects  were  found  to  be  effective,  and 
which  were  found  to  be  ineffective. 

The  IPPD  processes  are  divided  into  six  major  topics: 

•  Team  Selection 

•  Team  Development 

•  Design  Product  Development 

•  Product  Model  Development 

•  Build  Strategy  Development 

•  Metrics  Development 

The  design  process  described  herein  assumes  that;  the  shipyard 
designers  are  relatively  inexperienced  in  the  design  and 
arrangement  of  commercial  ship  engine  rooms;  available 
baseline  or  reference  ships  are  out-dated,  non-competitive  or 
require  extensive  modification  to  suit  current  requirements;  and 
few  or  no  commercial  standards  are  in  place.  As  experience  is 
gained  and  more  suitable  baseline  ships  become  available,  many 
of  the  recommended  design  process  steps  may  be  abbreviated  or 
converted  to  shipyard  standards  which  do  not  have  to  be 
redeveloped  for  each  successive  contract. 

IPPD  TEAM  SELECTION  AND  DEVELOPMENT 

This  section  provides  a  detailed  description  of  the 
recommended  approach  for  assembling  and  training  an  IPPD 
team.  The  start-up  of  any  project  requires  a  ‘champion’  to  sell 
the  project  to  company  management.  Once  the  project  has  been 
endorsed  the  following  steps  in  selecting  the  team  members  are 
recommended. 

Team  Selection  Process  Development 

The  first  and  most  important  step  is  to  establish  a  clear  task 
definition,  Figure  1,  prior  to  team  selection  so  that  the  team  can 
be  customized  to  the  task.  (4) 

A  well  defined  task  is  one  with  a  clear  vision  statement,  a 
clear  set  of  objectives  and  a  clearly  defined  set  of  strategies. 
These  elements  are  essential  to  a  project’s  success. 

As  a  first  step  in  clearly  defining  the  task,  the  Quality 
Function  Deployment  (QFD)  tool  (Reference  2)  should  be 
utilized  to  identify  the  8  or  10  top 


Figure  1.  Customizing  the  Team  to  the  Task 

customer  required  characteristics  for  the  product.  These  8  or  10 
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characteristics  should  then  be  used  to 

identify  the  skills  required.  See  Figure  2  for  the  recommended 
procedure  for  identifying  team  member  skill  requirements. 
Other  synergistic  methods,  such  as,  early  customer  involvement 
in  determining  customer  requirements  can  also  be  used.  It  is 
strongly  recommended  that  individual  opinion  approaches  to 
identifying  skill  requirements  be  avoided. 


DEVELOP  VISION 
OBJECTIVES  AND 
STRATEGIES  STATEMENTS 


PRODUCT* 

REQUIREMENTS 


*  LIMIT  TO  THE  8  OR  10 
PRIMARY  REQUIREMENTS 


Figure  2.  Identify  Team  Member  Skills  Process 
Flowchart 

The  selection  of  team  members,  in  many  ways,  is  similar  to 
normal  hiring  procedures  in  that  skill  requirements  vs.  cost  must 
be  a  factor.  It  is  essential  that  the  required  skills  to  provide  the 
characteristics  identified  in  Figure  2  be  provided.  Hence,  it  may 
be  necessary  to  acquire  support  sources  other  than  those  directly 
available  sources  within  the  company.  Not  all  team  members 
will  be  required  full  time.  It  is  recommended  that  the  core 
team/resource  team  concept  be  adopted.  The  part  time  resource 
team  personnel  should  participate  fully  in  the  team  training  and 
development  process.  See  Figure  3  for  the  recommended 
selection  process. 

The  following  is  the  recommended  team  composition  for  an 
engine  room  conceptual  design  team: 

Core  Team  Permanently  At  Design  Site 

•  Team  Leader 

•  Design  Engineers  -  8 

1 .  Hull/Structural  -  1 

2.  Piping  System  -  3 

3.  Machinery  Engineer  -  1 

4.  Outfitting/HVAC/Arrangements  -  1 

5.  Electrical  (Control  &  Monitoring)  -  1 

6.  Production  (T  &  E  /  Construction/Build 

Strategy)  -  1 

•  Computer-aided  Design  Team  Leader  -  1* 


Resource  Team  Permanently  At  Design  Site 

•  Computer-aided  Designers  (Including  Team  Leader)  - 
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•  (One  Designer  skilled  to  support  each 


PROJECT  SKILL 

REQUIREMENTS  & 

MATCH  SKILL 

QTY  FROM  QFD 

REQUIREMENTS 

ANALYSIS 

w 

TO  AVAILABLE 

SKILLS 

(SEE  FIGURE  3) 


LIST  OF  AVAILABLE 
NEW  HIRE  OR 
CONTRACT 
EMPLOYEE  SKILLS 


LTR  REQUEST  TO 
PARTICIPATE  TO 
SELECTED  QUALIFIED 
CANDIDATES  WITH 
COPY  TO  SUPERVISOR 


RESPONSE  FROM 

INTERESTED 

CANDIDATES 


LTR  AUTHORIZATION 
BY  EMPLOYEE'S 
CURRENT 

SUPERVISOR  TO  JOIN 
TEAM 


Figure  3.  Team  Selection  Process  Flowchart 

Design  Engineer) 

•  Design  Site  Administrative  Support  -  1 

Resource  Team  Periodically  At  Design  Site  (2-3  Weeks  in 
Duration ) 

•  Propulsion  Equipment  Vendor  Applications  Engineer 
-  1 

(Diesel,  Reduction  Gear,  and  Propeller  Representative 
as  needed) 

•  Ship  Owner/Operator  Representative  -  1 

*  This  position  may  be  eliminated  if  the  Core  team  has 
sufficient  computer  knowledge. 

Design  Project  Teambuilding/Training  Program 

A  summary  of  the  teambuilding  approach  is  presented  as  Figure 
4.  The  steps  are  further  elaborated  in  the  text  following. 

Step  1  -  Design  team  developments  should  start  with  an 
orientation  kick-off  meeting  which  outlines  the  goals  and 
objectives  of  the  selected  design  team.  These  goals  and 
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objectives  of  the  selected  design  team.  These  goals  and 
objectives  should  be  developed  by  a  Management  team  such  as 
a  Steering  Committee.  All  goals  and  objectives  should  have  the 
approval  and  buy-in  of  top  management  before  they  are 
presented  to  the  design  team.  It  is  essential  to  have  all  goals  and 
objectives  developed  before  the  training  of  the  team  begins,  this 
promotes  a  better  understanding  of  the  overall  project  from  the 
start. 

Step  2  -  Cross  functional  team  training  (5)  should  consist  of  the 
following: 

•  Preliminary  Team  Building  Activity 

•  Skills  and  Techniques  of  a  team  Player 

•  Success  Strategies  for  Cross-Functional  Teams: 

•  Concerns  and  Questions  Meeting  the  Steering 
Committee  Outline 

•  Cross-Functional  Team  Simulation 

•  Review  of  Key  Success  Factors 

•  Developing  Operating  Agreements  for  Design  Team 

•  Tools  and  Techniques  for  Effective  Team  Meetings 

•  Stages  of  Team  Performance:  Forming,  Storming, 
Norming  and  Performing  (2) 

•  Team  Environment  (Collocation) 

Step  3  -  Team  meeting  training  should  be  provided  to  the  entire 
design  team  which  should  include  formal  training  in  the 
following  skills: 

•  Facilitation  (controlling  a  meeting), 

•  Process  Observation  (reviewing  the  process  followed 
and  presenting  positive  and  negative  aspects  of  the 
meeting,  referred  to  as  plus  and  deltas)  and 

•  Scribing  (the  art  of  taking  notes  on  flip  charts  or  view 
graphs). 

Everyone  on  the  team  must  understand  the  importance  of 
these  three  factors  in  any  meeting  and  be  able  to  conduct 
themselves  in  a  manner  which  will  allow  all  three  skills  to  be 
practiced  most  efficiently. 

Step  4  -  Practice  working  as  a  team  by  applying  the  training 
concepts  in  a  team  setting..  It  is  recommended  that  the  core 
team  be  collocated  adjacent  to  a  large  dedicated  meeting  room 
where  information/development  data  can  be  posted  for  the 
team’s  constant  review.  Excellant  resources  for  team  related 
problem  solving  are  references  (6)  and  (7).  It  is  recommended 
that  references  (8)  through  (15)  be  required  reading  for  this 
step. 

Step  5  -  1PPD  training  should  consist  of  the  following. 

•  Team  Management  Practices 

•  Team  Planning  Session:  Norms,  Mission, 
Organization 

•  Communication  Planning 

•  Team  Planning  Session:  Communication  Plan 

•  Customer  Focus 

•  Team  Planning  Session:  Customer 

•  Requirements 

•  Project  Management  for  1PPD:  Core  Team  and 
Support  Ring 

•  Team  Planning  Session:  Evaluation  of  Architecture 


•  Team  Planning  Session:  Task  Plan  and  Subteam 
Assignment 

•  Performance-Based  Measurement  (Metrics) 

•  Partnership  Agreement,  Next  Steps  Team  Planning 
Session 

At  this  point  of  team  development  it  is  imperative  that  the  team 
develop  a  team  dynamics  measurement  tool.  This  tool  should 
be  designed  to  help  the  team  improve  their  performance  in  the 
areas  that  are  considered  important  to  the  team  development 
process.  The  focus  of  this  tool  is  to  build  on  successes  and  to 
identify  and  correct  specific  problems  based  on  the  team’s 
norms. 

Step  6  -  Practice  as  a  team  by  developing  the  following  major 
subteams. 

•  Core  Team 

•  Communication 

•  Team  Agreements 

•  Training 

•  Resource  Management 

•  Technology  Management 

•  Vendor  Furnished  Information  (VFI) 

Step  7  -  Strategic  Design  method  training  (4)  must  consist  of 
the  following. 

•  Why  Concurrent  Engineering  Works 

•  Process-Based  Design:  A  Concurrent  Engineering 
Methodology 
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Step  1 


Step  2 


Step  3 


Step  4 


Step  5 


Step  6 


Step  7 


Step  8 


Step  9 


Step  10 


Step  1 1 


Step  12 


Practice  Working  as  a  Team 
Using  Tools/Database 


Figure  4.  Teambuilding/Training  Process  Flowchart 

•  The  Six  Concurrent  Engineering  Skills 

—  How  to  Analyze  Product  Requirements 
—  How  to  Build  A  Winning  Strategy 
—  How  to  Create  Competitive  Designs 

—  How  to  Rate  Designs 

—  How  to  Reduce  Design  Cycle  Time 
—  How  to  Build  Team  Success 

•  Best  Practices  of  Winning  Teams 

•  Case  Studies 


•  The  Teamwork  Approach  to  Product  Development 

•  Guidelines  for  Concurrent  Product  Development 
All  of  the  above  are  necessary  skills  the  team  must  learn  to 
successfully  complete  the  concurrent  engineering  design 
process.  This  concurrent  engineering  process  should  bring  the 
following  to  the  team. 

•  Put  Process  and  Product  in  Perspective 

•  Emphasis  on  Problem  Seeking 

•  Excellent  first  step  in  design  process 

•  Systematic  approach  to  any  design  process 
Step  8  -  The  team  as  a  team,  or  several  smaller  teams,  must 
practice  the  necessary  skills  on  a  small  design  project  to  gain 
experience  in  these  methods.  After  several  iterations  of  the 
Strategic  Design  road  map;  the  design  team  should  be  able  to 
develop  a  Strategic  Design  Brief  in  a  three  day  period.  First 
time  development  is  best  achieved  with  the  assistance  of  a 
professional  coach.  (4)  The  intent  of  this  Strategic  Design  Brief 
is  to  outline  the  design  team’s  direction  in  developing  the 
project,  and  gain  management’s  (Steering  Committee)  buy-in. 
Step  9  -  The  team  must  be  trained  in  the  use  of  design  tools 
such  as  QFD.  This  tool  is  designed  to  focus  on  customer 
requirements,  product  and  process  characteristics  and  tasks. 
QFD  is  a  fairly  complicated  process  and  should  be  taught  by  a 
qualified  professional  instructor.(5)  This  tool  can  be  used  to 
identify  all  process  and  product  tasks  needed  to  complete  a 
detailed  design  process.  The  effort  should  focus  on  the  critical 
points  e.g.  the  team  has  to  go  deep  into  the  build  strategy  and 
just  superficially  into  sewage  and  drainage  system  concepts. 
Step  10  -  The  team  must  practice  using  design  tools.  It  is 
suggested  the  team  develop  QFD  subteams  to  develop  process 
and  product  houses.  This  exercise  should  produce  a  complete 
set  of  design  tasks. 

Step  11  -  Establish  a  subteam,  including  computer  support 
experts,  to  identify,  implement,  and  support  the  computer 
applications  required  for  all  process  and  product  activities  for 
team  members  and  external  resources  (Steering  Committee, 
shipyards,  owners,  vendors  etc.).  The  subteam  must  use 
advanced  communication  software  between  external  resources 
to  keep  the  record  and  maximize  cooperation  with  external 
resources. 

Step  12  -  The  computer  applications  subteam  should  develop 
“Computer  Applications  User’s  Guide”  and  a  training  program 
to  allow  the  implementation  without  interruption  of  team 
member’s  daily  project  activities.  An  adequate  amount  of  time 
must  be  provided  for  every  team  member  to  practice  using  these 
tools. 

It  is  suggested  that  a  professional  IPPD/Concurrent 
Engineering  coach  be  present  with  the  team  throughout  the 
development  of  the  team  to  give  guidance  and  support  in  the 
development  of  individual  teaming  skills. 

The  team  should  devote  as  much  time  as  possible  to 
understanding  the  objectives  of  the  training,  especially  team 
building.  This  will  create  a  greater  feeling  of  comfort  with  the 
IPPD  process  and  tools. 

The  design  team  must  understand  that  there  is  no  “perfect 
ship”,  but  just  a  full  integration  between  shipbuilders  and 
shipowners,  which  allows  for  sacrifice  of  some  aspects  to 
increase  others,  depending  on  priorities  of  both  sides  to  reach  an 
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agreement.  Shipbuilders  and  shipowners  should  be  partners, 
not  rivals. 

Pitfalls 

The  following  pitfalls  must  be  eliminated  to  have  a  successful 
team  environment. 

•  Management  expecting  product  output  during  the  three  to 
six  month  team  development  period. 

•  External  management  allowing  team  members  to  bring 
team  problems  outside  the  team  for  resolution. 

•  Not  empowering  the  team  to  remove  ineffective  team 
members. 

ENGINE  ROOM  DESIGN  PRODUCT  DEVELOPMENT 

This  section  provides  a  description  of  the  recommended 
approach  for  the  design  of  an  engine  room. 

Product  QFD  Development  Process 

This  section  is  written  assuming  the  reader  has  a  basic 
knowledge  of  QFD,  QFD  houses,  house  rotation,  and  QFD 
house  interaction  scoring  and  weighting.  See  Reference  (5)  for 
detailed  information  on  QFD. 

By  having  a  product  sub-team  composed  of  customers, 
operators,  engineers,  designers,  production  representatives  who 
know  how  to  use  the  QFD  tool,  a  Product  QFD  House  can  be 
developed  using  the  process  described  in  Figure  5.  Working 
groups  for  QFD  houses  should  be  no  larger  than  eight  and  the 
participants  should  be  committed  to  completing  the  task. 
Individuals  should  refrain  from  coming  and  going  at  will  as 
continuity  is  not  maintained.  During  this  session  the  customer 
requirements  are  identified  and  prioritized  by  the  customer  and 
the  characteristics  of  the  product  are  identified  by  the  customer 
and  the 


Figure  5.  Product  QFD/Task  Development  Process 
Flowchart 

QFD  subteam.  It  is  very  important  to  get  customer  input  during 
the  analysis  to  help  answer  any  questions  or  uncertainties  that 
arise  regarding  owner  requirements. 

Prioritization  of  the  product  characteristics  is 
accomplished  by  identifying  the  interactions  between  the 
requirements  and  the  characteristics  and  the  level  of  importance 
of  each  interaction.  All  items  on  the  house  axes  need  to  be 
clearly  defined  and  agreed  upon  prior  to  doing  the  QFD  analysis. 
This  will  help  in  resolving  possible  disputes  and 
misunderstandings  later  on  in  the  analysis.  Participants  should 
endeavor  to  keep  the  number  of  items  on  any  single  axis  as  low 
as  possible.  The  addition  of  a  single  item  requires  a  significant 
amount  of  time.  Items  may  be  deleted  or  combined  to  simplify 
the  QFD  house  or  the  house  may  be  split  into  smaller  houses. 
The  systems  to  be  included  are  brainstormed  by  the  team  and 
listed  on  the  horizontal  axis.  Interactions  between  the  systems 
and  product  characteristics  are  then  rated  and  prioritized. 


QFD  Completion 

The  QFD  houses  are  reevaluated  based  on  the  Strategic 
Design  Brief  results  to  ensure  that  the  focus  of  the  QFD  houses 
is  in  line  with  the  SDB.  QFD  House  3  is  developed  to  identify 
the  technical  design  tasks  required  to  meet  the  requirements  and 
to  prioritize  those  tasks. 

A  complete  list  of  subtasks  is  then  created  based  on  the  third 
QFD  House.  This  is  accomplished  by  comparing  each  of  the 
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systems  to  the  technical  design  tasks.  For  example.  Table  1  is 
an  exceipt  from  a  fuel  (purification)  system  comparison. 


System 

Fuel  (Purification) 


Technical  Design 
Task 

ER  Arrangement 


Master  Equipment 
List  (MEL) 

System  Diagram 


Design  Subtasks 

Locate  all 
equipment  within 
the  engine  room 
Develop  MEL  for 
fuel  purification 
equipment 
Develop  System 
Diagram  for  fuel  oil 
purification  system 


Table  1  Fuel  Purification  System  Design  Tasks 

Each  engineer  is  then  assigned  cognizance  over  one  or  more 
engine  room  systems  and  one  or  more  technical  design  tasks. 
System  cognizance  typically  requires  developing  calculations, 
diagrams,  specifications,  and  selecting  equipment  for  that 
system.  Task  cognizance  requires  completion  of  the 
administrative  jobs  associated  with  each  task.  These  might 
include  developing  drawing  formats,  numbering  schemes,  and  a 
list  of  standard  symbols.  The  assignments  are  made  based  on 
interviews  and  discussions  conducted  with  each  team  member 
to  determine  their  capabilities  and  preferences  while  attempting 
to  maintain  a  level  work  load.  A  typical  member's  work  load 
might  be  Table  II. 

Changes  to  the  tasking  may  occur  as  some  individuals  pass 
portions  of  their  system  responsibilities  to  others.  Many  of  the 
task  responsibilities  may  prove  to  be  far  too  large  to  be 
accomplished  by  a  single  individual  so  subteams  must  be 
created  to  further  reduce  the  time  requirements  for 


Systems 

High  Temperature  Central 
Freshwater  Cooling  System 
Low  Temperature  Central 
Freshwater  Cooling  System 
Potable/Drinking  Water 

Steam 

Fire  (Non-seawater) 


Design  Tasks 
System  Diagrams 
Component  List 
System  Diagrams 
Component  List 
System  Diagrams 
Component  List 
System  Diagrams 
Component  List 
System  Diagrams 
Component  List 


Table  II  Typical  Team  Member  s  Work  Load 

the  participants. 


The  phases  of  the  design  development  should  be  defined 
with  at  least  the  following  three  phases  identified: 

•  Conceptual  Phase  (Phase  1),  where  the  concepts  are 
established  and  settled,  based  on  the  main 
requirements,  kept  as  short  as  possible; 

•  Development  Phase  (Phase  2),  where  the  design  is 
developed  based  on  the  definitions  of  the  first  phase 
and  where  the  main  equipment  and  associated 
technical  data  should  be  carried  out;  and 

•  Refinement  phase  (Phase  3),  where  the  design 
incorporates  additional  internal  improvements  and 
refinements  as  well  as  external  comments. 

The  duration  of  each  design  phase  is  based  on  the  available 
baseline  design  documentation,  and  level  of  skill  and  experience 
of  the  participants.  The  schedule  should  include  a  time 
tolerance. 

The  schedule  should  be  available  to  all  team  members  for 
tracking  tasks  and  early  identification  of  the  areas  requiring 
assistance. 


Figure  6.  Product  Schedule  Development  Flowchart 


Project  Schedule  Development 

The  schedule  development  should  be  based  on  the  QFD 
product  house.  The  resulting  task  list  should  be  as  detailed  as 
possible,  presenting  every  task  and  sub-tasks  for  every  system. 

Project  and  task  completion  dates,  vacations  and  holidays, 
as  well  as  the  availability  of  core  team  and  resource  team 
personnel  should  be  known. 


3-D  PRODUCT  MODEL  DATA  DEVELOPMENT 
PROCESS 

In  order  for  the  product  model  to  be  integrated  into 
the  design,  construction,  and  business  practices  employed  at  the 
shipyard,  it  must  have  sufficient  detail  to  be  useful  in  making 
design  decisions.  The  type  of  data  and  level  of  detail  available 
in  the  product  model  needs  to  be  correlated  to  the  various  stages 
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in  the  design  process.  The  product  model  development  scenario 
is  based  on  the  following  assumptions: 

•  During  the  conceptual  design  stage,  the  product  model  is 
extremely  dynamic  but  the  level  of  detail  is  low. 

•  Early  stage  design  is  concentrated  on  system  diagrams. 

•  During  detail  design,  the  product  model  is  less  dynamic, 
but  the  level  of  detail  increases  greatly,  and  configuration 
management  becomes  complicated. 

•  During  the  construction  phase,  configuration  management 
is  the  most  difficult  due  to  the  introduction  of  the  many 
dissimilar  systems  required  to  support  the  manufacturing 
processes. 

•  The  majority  of  engineers/designers  do  not  have  access  to 
the  CAD  system. 

•  Many  engineers/designers  supply  data  to  one  CAD 
technician. 

The  product  model  development  process  can  be 
summarized  as  follows. 

•  Define  library  parts 

•  Hull  Definition 

•  Locate  Decks/Major  Bulkheads 

•  Define  Major  Structure 

•  Locate  Major  Equipment 

•  Locate  Tanks 

•  Arrange  remaining  equipment 

•  Define  Deck  and  Bulkhead  structure 

•  Define  distributed  systems  lanes 

•  Locate  major  piping 

•  Optimize  equipment  location 

•  Organize  equipment  into  units 

•  Structural  details 

•  Optimize  unit  location 

•  Define  foundations 

•  Arrange  minor  piping 

•  Optimize  distributive  systems 

In  addition,  for  the  product  model  to  be  useful  it  must 
support  the  development  of  the  documentation  required  for 
periodic  design  reviews  and  the  development  of  the  traditional 
drawings  at  the  completion  of  the  design. 

Software  Selection 

Software  has  to  be  obtained  to  create  and  access  the 
product  model  data.  There  are  no  commercial  off  the  shelf 
systems  which  can  adequately  support  ship  design  and 
construction  within  a  specific  business  context  without  being 
customized.  The  development  effort  required  to  integrate  the 
software,  ease  of  use,  and  reliability,  should  be  a  significant 
consideration  in  the  selection  process. 

One  of  the  most  important  steps  in  the  selection  of 
commercial  software  is  the  evaluation.  Software  must  be 
evaluated  in  the  context  it  will  be  used  in  the  shipyard.  The 
evaluation  should  include  at  least  a  prototype  implementation  in 
which  interfaces  are  developed  to  all  major  shipyard  processes. 
The  implementation  should  be  phased,  based  upon  the 


requirements  of  existing  and  planned  projects. 

Personnel  Selection  and  Training 

An  ideal  CAD  user  is  an  experienced  designer  and  engineer 
with  an  expert  understanding  of  the  application  software.  The 
user  needs  to  be  trained  not  only  in  the  use  of  the  system,  but 
must  be  familiar  with  the  design  and  construction  processes  as 
well.  It  is  very  important  to  integrate  actual  examples  of 
shipyard  processes  into  the  training  process  in  order  to  reinforce 
the  theory  as  well  as  to  prepare  the  user  for  actual  tasks.  The 
CAD  team  should  consist  of  a  core  of  application  experts  who 
can  provide  some  guidance  in  addition  to  performing  their  own 
tasks.  Initially,  inexperienced  users  should  develop  library  parts 
and  assist  the  application  experts.  As  they  gain  experience  they 
will  require  less  guidance  and  can  be  assigned  more  difficult 
tasks.  Cross  training  should  be  performed  where  practical  in 
order  to  provide  awareness  of  the  overall  product  model  as  well 
as  to  develop  a  reserve  of  users  to  accommodate  a  shifting 
workload. 

Other  resources  required  to  support  product  model  development 
include  system  support,  application  programming,  and  library 
part  development.  The  system  support  role  does  not  really 
require  knowledge  or  experience  with  the  application  software. 
The  application  programmers  should  have  a  great  deal  of 
knowledge  and  experience  with  the  software.  Experience  and 
knowledge  of  the  ship  design  and  construction  processes  is 
highly  desirable.  Library  part  modelers  should  have  an  expert 
understanding  of  the  CAD  application  and  an  understanding  of 
the  level  of  detail  required  to  represent  a  component. 

Experience  and  knowledge  of  the  ship  design  and  construction 
process  is  not  necessary.  Notice  the  level  of  experience  for  the 
application  programmers  and  library  part  modelers  are  opposite 
of  the  ideal  CAD  user.  Additional  training  is  required  for  non 
CAD  users  who  require  access  to  the  product  model.  This 
training  should  consist  of  visualization  and  redlining  techniques 
in  order  to  review  and  comment  on  the  work  in  progress. 
Application  of  IPPD  process  by  the  CAD  sub  team  is  critical  due 
to  the  close  interaction  between  all  the  roles  involved  in  product 
model  development. 

Product  Model  Preparation 

Before  a  product  model  can  be  developed,  an  infrastructure 
must  exist  which  includes  configuration  management, 
procedures,  components  and  commodity  items,  and  system 
support.  The  process  of  developing  the  product  model  requires 
the  identification  and  modeling  of  equipment,  outfit,  and 
furnishings  before  these  items  can  be  inserted  into  the  model. 
The  product  model  is  highly  dependent  upon  the  availability  of 
commodity  parts  such  as  structural  steel  shapes,  major 
equipment,  outfit  and  furnishings,  valves,  fittings,  etc.  The  first 
ship  designed  using  the  system  is  generally  the  hardest  because 
in  addition  to  design  and  construction,  the  infrastructure  is 
under  development. 

Library  Parts  and  Commodity  Parts 


Since  commercial  CAD/CAM  systems  are  used  to  develop 


arrangements,  structural,  and  distributed  systems  models  it  is 
highly  desirable  that  this  data  be  provided  in  a  digital  format. 
This  data  consists  of  the  information  required  to  represent  the 
as-built  geometric  definition  of  the  component  as  well  as  the 
attributes  required  to  convey  non-graphic  information.  The 
vendor  files  should  be  accessible  to  all  CAD  workstations  for 
reviewing,  printing  and  referencing  as  a  “footprint”  for 
modeling.  A  database  should  be  developed  which  provides 
information  about  the  availability  of  the  data  and  the 
developmental  status  of  the  library  parts.  It  is  recommended  that 
a  group  be  established  to  support  the  product  model  library 
consisting  of  CAD  users  and  personnel  who  can  obtain  and 
document  the  data  required  to  build  the  equipment.  The  best 
practice  is  to  receive  the  data  formatted  specifically  for  the 
product  modeling  system.  This  will  require  a  partnership 
between  the  shipyard  and  suppliers. 

Product  Model  Procedures 

Due  to  the  complexity  and  the  all  encompassing  scope  of 
the  product  model,  a  set  of  procedures  and  guidelines  must  be 
established  to  ensure  that  the  product  model  will  be  developed 
in  a  consistent  fashion.  There  should  be  a  general  set  of 
guidelines  which  pertain  across  all  applications  as  well  as 
application  specific  guidelines.  For  example,  configuration 
management,  general  model  organization,  product  work 
breakdown  system,  and  component  modeling  procedures  will 
probably  be  the  same  across  applications  because  they  affect  the 
product  model  globally.  Value  added  modifications  to  the 
product  model  such  as  manufacturing  data  or  engineering 
analysis  data,  which  have  a  local  effect  between  a  limited 
number  of  groups,  require  unique  procedures.  The  procedures 
need  to  consider  not  only  how  the  product  model  will  be  used  to 
perform  a  specific  task,  but  the  effects  on  other  users  as  well. 

Product  Model  Usage 

In  general  it  is  best  to  have  a  single  product  model  which 
can  be  accessed  in  a  distributed  environment  by  all  ‘electronic’ 
design  and  construction  processes  (e.g.  arrangements, 
distributed  system  layout,  structural  design,  pipe  flow  analysis, 
structural  analysis,  naval  architecture,  plate  nesting,  pipe 
bending,  etc.).  This  means  the  sophistication  of  the  product 
model  varies  among  the  shipyards.  The  uses  of  the  product 
model  must  be  known  in  advance.  For  instance  if  the  end 
product  of  the  product  model  is  the  creation  of  drawings,  a 
radically  different  approach  will  be  undertaken  than  if  the 
product  model  will  be  used  directly  to  support  ship  construction. 
A  process  must  also  be  developed  for  product  model 
development.  The  definition  of  the  product  model  as  well  as  its 
development  and  implementation  necessitates  the  involvement 
of  all  groups  which  will  be  creating  as  well  as  accessing  product 
model  data.  The  sequencing  of  access  to  the  model  must  also 
be  determined,  including  the  output  products  required  to 
facilitate  communication  of  the  information.  Currently,  access 
to  the  product  model  by  others  than  CAD  users  are  through 
annotated  sketches  generated  from  the  product  model.  This  is 
also  the  predominant  methodology  used  for  design  review. 
Anyone  who  has  input  into  the  design  must  be  trained  and  given 


access  to  the  product  model.  Design  reviews  should  be 
facilitated  using  electronic  mockups. 

Product  Model  Development 

The  product  model  can  be  initiated  from  many  different 
sources,  including  existing  product  models,  CAD  drawings,  and 
paper  sketches/drawings.  Also  in  the  conceptual  phases,  much 
of  the  3-D  layout  is  unknown.  The  system  must  be  able  to 
accommodate  new  ideas  and  scanned  images.  The  first  iteration 
of  a  new  design  can  manifest  in  any  of  the  three  formats.  As  the 
arrangements  evolve,  the  CAD  technician  populates  the  product 
model  and  generates  models  and  sketches  as  defined  in  the 
product  model  development  procedures.  The  next  step  is  the 
definition  of  pipe  lanes.  As  the  model  becomes  more  mature,  it 
becomes  suitable  for  providing  the  documentation  required  for 
the  design  review.  Once  the  piping  lanes  have  been  identified 
the  distributive  systems  can  be  defined  in  more  detail  in  the 
product  model.  This  more  complete  product  model  would  be 
used  to  optimize  equipment  arrangement  and  begin  the 
grouping  of  equipment  into  units.  As  the  units  evolve,  the 
foundations  can  be  modeled,  and  structural  details  can  be 
designed.  Although  product  model  development  lags  slightly 
behind  the  optima  time  in  which  data  should  be  provided  to  the 
designer,  the  data  can  be  delivered  in  time  to  have  a  positive 
influence  on  the  design.  This  cycle  is  repeated  until  the  design 
phase  has  been  completed. 

Product  Model  Output  Products 

Output  products  are  used  to  provide  information  to 
downstream  processes  and  interim  documentation  and  may  be 
the  final  end  products  as  well.  For  example,  graphics  files 
required  by  a  visualization  system  for  design  reviews  is  an  end 
product.  Work  packages  generated  from  the  product  model  in  a 
paper  format  may  be  required  on  the  waterfront  by  the  trades. 
Final  drawings  are  still  a  requirement  in  most  applications.  In- 
process  output  products  include  finite  element  models, 
equipment  lists,  and  numerical  control  instructions.  Sketches 
generated  from  the  model  may  be  required  to  convey 
information  to  the  system  engineer  who  does  not  have  product 
model  access. 

•  Design  Documents  (released  continuously) 

—  Sketches 

—  Reports 

—  Visualization  files  (shaded  images,  hidden  line) 

—  Manually  created  2-D  Schematics  (provided 
upon  request) 

•  Design  Review  Documentation  (released  periodically) 
—  Annotated  drawings  required  to  communicate 

system  diagrams  and  arrangements 

•  Visualization  files  (Documentation  (released  semi¬ 
weekly) 

—  Product  Model  Review  files  downloaded 

•  Product  model  neutral  databases  (as  requested) 

This  data  will  initially  be  provided  in  the  format  as  defined 
in  digital  data  exchange  procedures.  Long  term  plans  are  to 
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provide  the  data  in  Standard  Technical  Exchange  Program 

(STEP)  format  conforming  to  the  ship  design  and  construction 

application  protocols: 

—  Arrangement; 

—  Structure; 

—  Distributed  systems;  and 
—  Library  parts. 

•  Final  Drawings  (end  of  project) 

This  requires  major  rework  of  the  latest  design 
documentation.  These  drawings  shall  be  developed 
explicitly  front  the  product  model  and  annotation 
added  manually  as  required.  Editing  of  line  style  shall 
be  performed  as  required.  This  process  is  developed 
after  the  product  model  has  been  completed,  and  will 
be  non-associative  to  the  product  model. 

—  Paper  drawings 

—  Raster  images 

—  Drawing  Interchange  File  (DXF)  files  (2-D) 

—  Initial  Graphics  Exchange  Specification  (IGES) 
files  (2-D) 

Hierarchy  for  the  Acquisition  of  Commodity  and  Library 

Part  Data 

1.  Provide  digital  data  in  native  format  in  conformance  to 
product  modeling  library  development  guidelines. 
Basically,  this  data  consists  of  geometry  for  the  various 
representations  of  the  part  (e.g.  detail,  2-D  symbolic, 
envelope,  etc.)  and  the  non-graphic  attributes  for  the 
required  level  of  intelligence. 

2.  Provide  the  geometry  and  attributes  using  the  appropriate 
National  Shipbuilding  Research  Program  (NSRP) 
specification  for  the  definition  of  STEP  application 
protocol  for  shipbuilding. 

3.  Provide  the  geometry  and  attributes  using  the  Initial 
Graphics  Exchange  Specification  Version  5.2  or  greater. 
Multiple  formats  are  available  within  IGES  to  represent 
this  data.  The  preferred  method  would  be  to  use  CSG  and 
Brep  solids  to  represent  the  geometry  and  the  attribute 
table  and  instance  entity  to  represent  attributes.  In  the 
event  the  preprocessor  is  not  robust  enough  to  handle 
solids,  then  surfaces  or  wireframe  geometry  would  be 
used.  If  the  preprocessor  is  not  robust  enough  to  handle 
the  attribute  table  and  instance  entities  then  a  text  file 
would  be  used. 

4.  Provide  the  geometry  using  DXF,  and  the  attributes  using 
a  text  file.  The  preferred  DXF  geometry  type  would  be 
surfaces,  however  wireframe  is  acceptable  if  surfaces  are 
not  available. 

5.  Provide  the  data  in  native  format  AutoCAD  or 
Microstation. 

6.  A  scanned  image  of  the  applicable  technical  publication 
describing  the  component  would  be  used  and  the  attribute 
data  would  be  provided  in  a  text  file.  Regardless  of  the 
methodology  used  to  represent  the  vendor  data,  it  is  highly 
desirable  for  a  raster  image  of  the  technical  documentation 
be  provided. 


7.  Provide  sufficient  technical  documentation  to  develop  a 

CAD  model  of  the  exterior  of  the  component,  including 

the  location  and  orientations  of  connections  (structural, 

fluid,  electrical). 

SHIP  S  SYSTEMS  DEVELOPMENT 

The  System  Development  Process  is  shown  on  the 
flowchart  of  Figure  7.  Development  of  systems  starts  when  the 
systems  are  identified  in  the  QFD  product  house  and  ranked 
according  to  how  difficult  they  are  to  implement  and  how  they 
interact  with  other  systems.  After  the  systems  are  identified,  the 
product  subteam  assigns  the  systems  to  individual  core  team 
engineers.  System  assignment  is  based  on  the  time  required  to 
develop  each  system  and  core  team  knowledge.  At  this  point, 
each  engineer  develops  his  system  concurrently  with  all  of  the 
other  systems.  System  concepts  can  be  refined  throughout  the 
conceptual  and  development  phases  along  with  trade-off  studies, 
equipment  selection,  owner/operator  input,  build  strategy  and 
during  the  level  of  unitization  defined  during  Phase  2. 

The  core  team  defines,  selects  or  adopts  a  proven 
baseline  for  all  systems  before  the  start  of  a  design.  This  will 
pay  off  downstream  with  regard  to  minimizing  the  time  spent  in 
discussion  within  the  team  about  content.  It  also  supports  the 
team  by  reducing  the  'blank  sheet  of  start-up  time.  Systems 
such  as  the  following  are  to  be  considered. 

•  Exhaust  Gas 

•  HVAC 

•  Sounding/V enting  &  Overflow 

•  Structure 

•  Fuel  Oil  Supply  and  Purification 

•  Sea  water 

•  Propulsion 

•  etc. 

Systems  specifications  need  to  be  defined  at  the  start  of  the 
project.  System  requirements  should  be  changed  to  match 
commercial  practice  on  world  class  ships  as  defined  by  the  core 
team  and  owner/operators. 

Diagrams 

A  diagram  subteam  can  be  established  early  in  Phase  1  to 
create  rules  and  guidelines  for  system  diagrams  and  to  select  the 
2D  CAD  software  for  engineers  to  create  the  system  diagrams. 

It  is  necessary  to  agree  to  use  only  one  type  of  software  for  these 
diagrams.  Also,  a  universal  list  of  equipment  symbols  and  valve 
symbols  must  be  used  to  promote  consistency  amongst  the 
system  diagrams. 

The  level  of  detail  listed  on  the  diagrams  must  be 
agreed  upon  for  all  system  oriented  diagrams.  This  level  should 
require  clear  presentation  of  system 
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Figure  7.  System  Development  Flowchart 

function,  ease  of  understanding,  and  system  interaction  must  be 
identifiable  with  references  to  other  diagrams 
where  needed.  The  equipment  on  the  diagrams  should 
be  positioned  similar  to  the  actual  room  arrangement  to  later 
simplify  the  unitization  breakdown  process. 

The  revision  and  approval  process  of  the  diagrams  and 
drawings  need  to  be  properly  defined  prior  to  the  completion  of 
the  first  diagram. 

Trade-Off  Studies 

Trade-off  studies  on  system  design  philosophies  and 
equipment  selection  should  been  done  throughout  Phase  1  and 
Phase  2.  The  initial  system  concepts  can  be  based  on  the 
following  items. 

•  The  system  concept  to  be  commercially  viable 

•  The  baseline  ship 

•  The  eight  key  Tllities"  listed  in  the  SDB 

•  Ship  rider  reports 

•  Owner/Operator  written  comments 

•  Core  team  input/evaluation 

Goals  for  the  trade-off  studies  are  as  follows: 

•  Create  a  simple,  but  efficient  system  that  is 
commercially  viable,  a  proven  concept,  easy  and 


economical  to  build  and  operate  that  provides  high 
reliability. 

•  Reduce  in  number  of  equipment,  thereby  minimizing 
the  equipment  to  be  maintained 

•  Reduce  the  amount  of  sea-water  piping  to  reduce 
problems  as  the  ship  ages  and  the  sea  water  piping 
corrodes 

Equipment  Selection 

The  equipment  selection  process  must  be  defined  for  the 
project.  The  vendor  furnished  information  library  needs  to 
support  the  equipment  selection  process  and  allow  access  for 
engineers  to  look  for  equipment  and  vendors.  In  many  cases 
that  the  support  from  vendors  takes  too  much  time  and  is  a 
constraint  for  the  engineers  and  the  schedule.  The  need  for 
drawings  and  information  will  be  a  great  concern  for  the  team  if 
the  vendors  are  not  as  willing  to  provide  information. 

Project  Database 

A  project  database  must  be  able  to  manage  conceptual 
design  and  formation  in  a  central  manner.  From  this  database, 
reports  covering  design  information,  master  equipment  list,  parts 
list,  list  of  units  and  blocks  could  be  generated.  Other  uses 
included  capturing  data  for  the  electric  load  analysis  and 
automation  and  signal  list.  Several  examples  of  the  database 
content  can  be  found  in  the  ERAM  design  package. 

PRELIMINARY  DEVELOPMENT  OF  ENGINE  ROOM 
ARRANGEMENT 

This  initial  step  of  engine  room  arrangement  involves 
propulsion  unit  identification  and  integration  within  the  engine 
room  envelope.  Additional  studies  can  be  performed  to  specify: 

•  Tank  top,  main  grating  and  intermediate  flat  levels; 

•  Main  engine  foundation; 

•  Height  of  the  shaftline; 

•  Location  of  the  engine  room  bulkheads; 

•  Location  of  the  fuel  oil  tanks;  and 

•  Location  of  stack/casing. 

This  development  of  this  step  is  done  using  2-D  drawings 
derived  from  the  3-D  model. 

The  main  items  of  the  preliminary  engine  room 
arrangement  identified  in  the  first  step  are  presented  to  the  team. 
During  this  discussion  the  main  drivers  for  spatial  relationships 
can  be  identified. 

Development  Of  Engine  Room  Arrangement  Options 

Engine  room  arrangements  can  now  be  developed  by 
individual  team  members  or  subteams  to  provide  several 
options.  Affinity  diagrams  and  the  “QFD”  house  matrix.  Figure 
5,  are  valuable  tools  at  this  stage.  Concurrently  a  preliminary 
pipelane  arrangement  study  can  be  performed. 

These  arrangements  are  now  presented  to  the  team  with  an 
explanation  of  each  concept  and  configuration. 
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Selection  Of  One  Option  For  The  Engine  Room 
Arrangement 


ENGINE  ROOM  ARRANGEMENT  DEVELOPMENT 


For  each  option  “plus  &  deltas”  and  “QFD”  analysis  are 
applied  to  validate  and  select  the  preferred  option. 

The  preferred  option  selected  by  the  team  can  now  be 
optimized  to  further  improve  the  arrangement  and  incorporate 
the  best  features  from  the  discarded  options  if  necessary. 
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Figure  8.  Engine  Room  Arrangement  Process  Flowchart 
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Figure  9.  Build  Strategy  Development  Flowchart 

The  arrangement  can  now  be  populated  using  the  3D  model 
and  data  base.  Development  of  system  pipelanes  from  earlier 
studies  can  now  be  included  in  the  3D  model.  As  the  3D  model 
is  developed  detailed  arrangements  can  be  accurately  produced 
at  any  time  with  minimal  effort.  Final  arrangements  are  a 
feature  of  the  completed  3D  model. 

BUILD  STRATEGY  DEVELOPMENT 

Build  strategy  development  is  initiated  in  parallel  with  the 
engine  room  arrangement  studies  and  system  diagram 


development.  See  Figure  9. 

This  process  includes  initial  system  design  steps  to: 

•  Simplify  systems; 

•  Combine  system  functions; 

•  Minimize  number  of  components; 

•  Define  intersystem  relationships;  and 

•  Define  system  level  units 

using  such  tools  as  affinity  diagrams  (See  Figure  10),  equipment 
association  tables,  networks,  and  analysis  of  system  schematics. 

Development  of  the  build  strategy  begins  with  the 
provisional  establishment  of  block  boundaries,  in  accordance 
with  the  following  principles 

Program  Considerations 

Interim  products  must  fit  the  characteristics  of  the 
shipyard  and  block  breaks  and  erection  sequences 
should  be  compatible  with  the  production  strategy 
developed  during  GBS  Phase  II  for  the  total  ship.  The 
overall  production  strategy  must  support  the  goals  of 
the  Strategic  Design  Brief  and  the  Requirements 
Document,  including: 

•  Ship  delivery  schedule  after  contract  award; 

•  Engine  room  cost; 

•  Latest  feasible  delivery/installation  of  main 
engine;  and 

•  Minimum  design/marketing  cost  and  no  financial 
commitments  (e.g.  for  long  lead  material)  prior  to 
contract  award. 

Logic  and  Criteria 

Favor  outfitting  in  any  tradeoff  between  structural  and  outfit 
production  and  maximize  interim  product  size  within  the  facility 
constraints.  Standardize  components,  arrangements  and 
interim  product  configurations.  Other  factors  to 
consider  include: 

•  Move  work  to  the  earliest  feasible  stage 

•  Installation 
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Figure  10  Engine  Room  Systems  Affinity  Diagram 


•  Testing; 

•  Minimize  joint  (weld)  length;  and 

•  Provide  flexibility  to  allow  for  the  unexpected. 

Production  Process  and  Sequence 

Assemble  blocks  on  flat  surfaces  (usually  decks)  on  the 
assembly  floor  (no  pylons,  minimize  use  of  pin  jigs).  Provide 
for  parallel  processing  of  interim  products  and  install 
all  possible  components  on  unit  Install  units  on-block 
wherever  weight  limits  permit,  otherwise  on-berth  and  use 
grand  blocks/units  to  increase  the  efficiency  of  the  on-berth 
erection  process.  Maintain  open  access  to  all  blocks 
containing  outfitting,  including  a  window  for  blue  sky 
outfitting  on-berth.  Include  the  following  items  in  the 
development  of  the  build  strategy. 

•  Minimize  time  between  material  delivery  and  ship 
delivery  (“just  in  time”) 


—  Install  main  engine  as  close  to  launch  as 
possible  (late  installation) 

•  Minimize  time  between  keel  and  delivery 

•  Load  hook  up  (free  ride)  material  on-block 

•  Complete  test  and  paint  structural  tanks  prior  to 
block  erection.  Use  free  standing  tanks  where 
feasible. 

•  Complete  block  painting  in  paint  facility  prior  to 
erection 

Interim  Products 

Configure  blocks  with  at  least  one  flat  surface  wherever 
feasible,  to  facilitate  assembly  and  to  provide  enclosed  spaces  for 
functions  not  amenable  to  unitization,  such  as  workshops  and 
stores.  Maximize  the  use  of  outfit  units  by 
incorporating  the  following. 
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•  System  units  which  can  be  standardized,  vendor 
furnished 

•  Large  integrated  units,  possibly  integrated  with 
ship  structure  at  the  assembly  stage 

Having  defined  the  major  interim  products,  the  next  priority 
is  the  assembly  and  erection  sequence.  An  erection  sequence 
and  schedule  is  created,  based  on  the  baseline  erection  schedule. 
This  schedule,  represents  the  current  capability  of  a  shipyard.  In 
the  engine  room  area,  adjustments  are  made  to  provide  for: 

•  Provision  of  open  (“blue  sky”)  time  for  unit 
the  erection  schedule  and  assembly  sequences 
loading; 

•  Opportunity  for  joining  blocks  into  grand 
blocks; 

•  Acceleration  of  Zone  4  erection  schedule  to 
support  shaft  installation  &  alignment;  and 

•  Late  installation  of  the  main  engine. 

Supporting  the  erection  sequence,  the  following 
approach  is  recommended  for  the  assembly  of  interim 
products  in  preparation  for  erection  on  berth. 

a)  Block  assembly  and  installation  of  in-tank 
piping,  structural  attachments  and 
foundations, 

b)  Grand  block  assembly  of  two  or  more  blocks, 
outfitting  of  grating/pipe  lane  units,  selected 
pipe  assemblies  and  foundations,  loading 
pallets  for  later  installation, 

c)  Erection  on-berth, 

d)  Loading  of  any  remaining  outfit  material 
during  the  open  period  prior  to  erection  of  the 
next  block.  This  includes  major  components 
and  units  which  are  costly,  have  a  critically 
long  lead  time,  or  are  too  large  or  heavy  to 
load  on-block. 

The  engine  room  block/grand  block  erection 
sequence  are  shown  in  an  erection  schedule.  For  each 
block,  the  sequence  and  schedule  allowed  for  one  week 
of  open  time  to  permit  on-berth  installation  of  outfit 
units  and  pallets.  In  addition,  the  machinery  casing 
area  is  kept  open  to  allow  two  weeks  for  main  engine 
installation  starting  ten  weeks  after  keel,  completing 
just  prior  to  deck  house  erection. 

The  erection  sequence  and  schedule  is  followed  by 
development  of  interim  product  assembly  sequences 
which  define  how  these  products  are  combined  prior  to 
erection  on  berth.  The  logic  and  criteria  used 
included: 


•  Assembly  of  subunits  and  units  within  the 
unit  shop,  including  the  integration  of  vendor 
furnished  units  where  appropriate; 

•  Assembly  of  grand  units  wherever  feasible, 
breaking  these  units  for  loadout  where 
necessary; 

•  Installation  of  grand  units/units  on  grand 
blocks  prior  to  erection  on-berth.  It  is 
assumed  that  on-berth  material  pallets  will 
also  be  loaded  on  the  blocks  prior  to  erection; 
and 

•  Units  too  large  or  heavy  to  load  at  this  stage 
will  be  loaded  on  berth. 

The  results  are  recorded  in  a  series  of  process  flow 
charts,  one  for  each  grand  block  involved. 

Finally,  using  the  erection  schedule  and  assembly  sequence 
described  above,  material  required  dates,  defined  in  terms  of 
weeks  before  or  after  keel,  are  determined.  Using  material  lead 
times,  the  required  time  for  order  placement  for  critical  material 
is  determined.  It  is  found  that  a  minimum  interval  of  12  months 
is  required  between  contract  award  and  keel  to  allow  for  the 
timely  receipt  of  long  lead  material  in  support  of  the  production 
strategy.  With  this  minimum  time  established,  the  remaining  6 
months  in  the  target  18  month  schedule  are  divided  between  the 
on-berth  and  overboard  periods. 

DESIGN  REVIEW  PROCESS 

The  design  review  process  should  be  as  open  and  objective 
as  possible,  giving  the  opportunity  of  discussions  between  the 
design  team  and  the  steering  committee  or  its  spokesperson. 

The  design  team  should  present  the  design  development, 
detailing  the  relevant  points  such  as  build  strategy  and  metrics. 
Then  the  steering  committee,  together  with  the  team,  must 
spend  the  necessary  time  in  analysis,  discussion  and  clarification 
of  design  issues.  This  is  best  done  on  a  one  on  one  basis.  This 
allows  individual  interface  between  steering  committee  and 
team  members  as  each  steering  committee  member  reviews 
each  system  design  storyboard. 

In  the  end  of  the  this  analysis  phase,  the  team  and  the 
committee  should  meet  to  discuss  the  results  and  to  capture 
comments  and  action  items. 

A  single  list  of  comments  requiring  action  should  be 
developed  and  agreed  upon.  The  team  answers  should  be 
addressed  as  soon  as  possible  in  order  to  incorporate  the 
comments  into  the  design. 

Figure  1 1  provides  the  recommended  in-process  design 
review  process. 

UNIT  DEVELOPMENT 

The  following  definitions  are  applied  to  unit  levels. 
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DESIGN  REVIEWS  1  AND  2  ONLY 


Figure  11  Design  Review  Process  Flowchart 

Level  i  -  On-Block  Outfit 

The  installation  of  individual  components  and  systems  on  hull 
structural  blocks.  This  approach  minimizes  miscellaneous  steel 
but  requires  heavy-lift  capability  (600-800  tons)  to  avoid 
extensive  on-board  construction. 

Level  2  -  Functional  L1  nils 

The  integration  of  functional  pipe  and  machinery  skids 
normally  dealing  with  major  sub-elements  of  individual 
functional  systems.  This  approach  moves  significant  complex 
piping  and  machinery  installation  from  on-board  to  on-unit  but 
requires  more  secondary  structure  and  design  integration. 


Similar  to  the  integrated  machinery  units  described  above, 
these  units  include  pipe,  machinery  and  electrical  work  in  a 
given  geographical  zone  of  the  ship.  In  addition,  through  the 
use  of  parametric  design  and  a  high  level  of  planning  prior  to 
developing  the  machinery  arrangement,  some  foreign  yards 
have  been  able  to  standardize  the  structural  framework  and 
system  interfaces  such  that  all  machinery  units  across  a  series  of 
ship  types  and  sizes  utilize  standard  structural  and  system 
interfaces.  This  approach  requires  the  highest  level  of  pre¬ 
planning  and  design  integration.  Secondary  steel  work 
requirements  are  similar  to  Level  3. 

The  build  strategy  concepts  and  the  level  2  units  should  be 
identified  in  the  early  stages  of  the  design  development.  See 
Figure  12  The  logical  grouping  of  distributive  system  runs  must 
also  be  considered  in  the 


Level  3  -  Large  Integrated  Units 

The  integration  of  large  machinery  units  including  all  pipe, 
machinery  and  electrical  components  and  systems  in  a 
geographical  area  of  an  the  engine  room.  This  approach 
effectively  moves  the  majority  of  piping,  machinery  and 
electrical  work  from  on-board  to  on-unit,  but  it  requires  a  higher 
level  of  design  integration  and  more  secondary  steel  work  than 
Level  2  as  the  units  are  larger  and  require  additional  support 
structure  for  lifting  and  handling.. 

Level  4  -  Standard  Machinery  Units 


Figure  11.  Level  2  Unit  Development  Flowchart 

early  stages. 

Tools  such  as  affinity  diagrams,  Figure  10,  or  equipment 
association  tables  should  be  used  to  guide  unit  definition.  The 
engine  room  arrangement  should  be  developed  trying  to  place 
the  potential  level  2  units  in  suitable  locations,  taking  into 
consideration  the  block  breakdown  and  pipelane  positions. 
Based  on  the  tools  used  for  system  development,  a  list  of  level  2 
units  should  be  developed. 

Parallel  to  the  arrangement  development,  level  3  units 
should  be  identified  (See  Figure  13)  and  the  component 
locations  should  be  adjusted  in  order  to  accomplish  this  level  of 
unitization. 
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Finally  a  complete  list  of  units  should  be  developed, 
presenting  what  components  are  included  on  level  2  units,  level 
3  units  and  block  assemblies. 

The  following  unitization  concepts  should  be  applied  to 
the  engine  room  design  development: 

•  Maximize  level  of  unitization,  thereby  avoiding  work 
onboard; 

•  Maximize  the  use  of  pipelanes  and  cablelanes,  to 
minimize  work  onboard;  and 


including  management; 

•  Shape  a  strategy  framework  to  guide  the  design 
thinking; 

•  Generate  creative  design  solutions; 

•  Develop  a  design  measurement  system;  and 

•  Create  a  “next  steps”  action  plan. 

The  basic  concept  of  strategic  design  method  is  to  identify, 
at  the  start  of  a  project,  the  desirable 


Figure  13  Level  3  Unit  Development  Flowchart 


•  Avoid  the  use  of  ship  structure  as  a  part  of  any  unit. 

METRICS  DEVELOPMENT 

The  use  of  metrics  is  a  key  element  of  the  Strategic  Design 
Method  and  the  development  of  metrics  are  an  integral  part  of 
the  development  of  the  Strategic  Design  Brief.  The  process  for 
metric  development  and  its  integration  into  the  Strategic  Design 
Brief  is  shown  on  Figure  14. 

Strategic  Design  Brief 

The  Strategic  Design  Brief  is  a  document  which  is  created 
in  an  intensive  24  hour  (3  working  days) 
period  to  accomplish  the  following: 

•  Define  the  design  problem  with  the  agreement  of  all. 


Figure  14.  Metrics  Development  Process  Flowchart 

properties  (“ilities”)  of  the  final  product  and  design  process,  set 
goals  for  each  property,  innovate  solutions  strong  points  in  both 
the  design  process  and  in  the  final  product.  They  keep  the 
design  team  and  management  in  touch  with  the  original 
concepts  of  the  project,  and  indicate  where  more  work  is  needed 
to  achieve  project  goals.  With  buy-in,  they  are  an  agreed  upon 
method  between  the  team  and  management  for  measuring 
project  success  in-process.  Post  process,  it  is  ultimately  the 
customer  that  measures  this  success. 

The  design  process  is  the  most  critical  element  to  drive  to 
consensus  in  the  early  stages  of  the  project.  All  of  the  “ilities” 
of  the  process  must  be  considered  while  innovating  solutions. 
Attention  must  be  paid  to  minimizing  expenditures  of  effort 
(“ings”)  which  achieve  little  progress  towards  the  goals. 

Metrics  Concepts  and  Objectives  Definitions 

For  the  achievement  of  these  goals,  and  set  up  a  measuring 
system  (the  metrics)  which  will  indicate  whether  the  goals  are 
being  approached  and  where  effort  must  be  focused  to  achieve 
the  project  objectives. 

Metrics  are  essential  for  indicating  weak  and  the  basic 
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method  for  establishing  a  metric  is  to  look  at  the  intent  of  the 
metric,  brainstorm  all  of  the  major  influences  (the  ilities)  for  that 
metric,  and  select  5  to  8  key  drivers  for  that  metric  that  are 
measurable.  Then  compare  those  5  to  8  key  drivers  to  the 
baseline  to  establish  a  reference.  The  normalized  ‘baseline 
ratio’  has  a  goal,  boundary  and  start  value  based  on  these  values 
of  the  drivers  compared  to  the  baseline.  Team  progress  is 
always  tracked  against  these  values.  The  concept  of  the 
boundary  value  is  the  minimum  required  to  break  into  the 
market. 

Brainstorming  and  selection  of  key  drivers  is  conducted  by 
the  team.  This  session  is  lead  by  the  most  skilled  or 
knowledgeable  people  of  the  team  in  each  of  the  metrics.  The 
open  discussion  within  the  team  will  ensure  quicker  team  buy-in 
than  forming  a  subteam  to  develop  recommendations  for  team 
buy-in. 

Buy-in  of  the  metric  is  essential  to  the  success  of  the  team, 
if  the  Steering  committee  has  rejected  a  metric  recommendation 
for  a  second  time,  it  may  be  necessary  for  a  subteam  to  review 
metric  basics.  A  quick  review  of  these  basics  will  indicate 
which  metrics  are  in  need  of  revision,  this  may  include  a 
redefinition  of  the  ‘ility’.  The  likelihood  of  metric  buy-in  is 
increased  if  the  complexity  and  time  required  to  calculate  the 
metric  values  are  reduced  by  remembering  that  team  buy-in 
does  not  mean  100%  satisfaction  of  all  the  stakeholders.  Once 
Steering  Committee  buy-in  has  been  achieved,  subteams  or 
individuals  are  assigned  to  develop  the  measurement  tool  for 
each  metric.  This  tool  is  submitted  to  the  team  for  buy-in  and 
then  the  Steering  Committee  again  following  the  process 
outlined  in  Figure  14. 

CONCLUSION 

The  application  of  the  IPPD  processes  to  the  ship  design 
process  at  U.S.  shipyards  can  significantly  reduce  the  man-hours 
and  duration  to  design  commercial  engine  rooms.  This  concept 
can  be  effectively  applied  to  the  entire  ship  design  process  if 
shipyard  management  fully  endorses  and  supports  a  corporate 
wide  IPPD  training  program.  In  addition  the  concurrent 
incorporation  of  customer  requirements  can  enhance  customer 
satisfaction  and  lead  to  repeat  orders. 

The  processes  that  each  team  should  develop  to  enhance 
their  success  in  an  IPPD  environment,  listed  in  descending  order 
of  importance,  follow. 

Consensus  Agreement  Process 

Consensus  basically  means  the  team  is  in  agreement  on  an 
issue.  This  process  should  be  the  very  first  process  invoked  by  a 
new  team  because  it  allows  the  team  to  make  decisions.  Having 
this  agreement  defined  in  writing  is  absolutely  necessary  to 
enable  a  team  to  function. 

Team  Norms  Development  Process 

Team  norms  must  be  developed  to  insure  that  all  team  members 
follow  certain  standards  that  each  team  member  has  agreed 
upon.  The  standards  will  range  from  how  work  should  be 
presented  to  mutual  respect  for  each  other.  The  amount  of 


importance  that  the  team  places  on  how  they  treat  each  other  as 
individuals  can  directly  affect  the  output  of  a  team.  Norms  are 
created  to  address  member’s  concerns  at  the  onset  of  team 
building  so  that  all  team  members  are  assured  of  “  riding  the 
same  bus  down  the  same  road  to  reach  the  same  goal”. 

Meeting  Management  Process 

A  meeting  management  process  is  necessary  in  order  to 
efficiently  utilize  the  attendees  time  and  capture  and  disseminate 
the  results  of  the  meeting.  There  are  three  basic  types  of 
meetings  used  to  manage  an  IPPD  team.  The  general  meeting 
attended  by  all  team  members  is  used  to  discuss  team  issues. 

The  Core  Team  meeting  is  used  to  discuss  technical  issues  and 
major  operating  decisions.  The  Week  In  Review  Meeting 
(WIRMj  is  used  to  manage  the  team  and  maintain  focus  of  the 
overall  objectives  and  goals  of  the  project.  This  WIRM  is  the 
most  important  meeting  tool  used  to  manage  the  team. 

Peer  Review  Process 

The  Peer  Review  is  a  tool  that  gives  the  team  members  a  chance 
to  confidentially  evaluate  their  peers  performance  and  make 
comments  in  a  positive  manner.  When  constructively  done  this 
is  a  excellent  self  improvement  tool.  This  is  an  essential 
element  to  a  successful  team  approach  but  one  that  must  be 
owned  by  the  team  and  properly  conducted  to  be  beneficial. 

The  process  could  be  modified  to  include  sharing  each 
individuals  results  with  the  team. 

Team  Member  Performance  Appraisal  Process 

The  team  member  performance  appraisal  is  a  tool  that  is  used  to 
provide  feedback  on  a  team  member’s  “TEAM”  performance 
to  his/her  supervisor.  Many  team  members  will  no  longer  have 
daily  or  even  weekly  contact  with  their  actual  supervisors  due  to 
their  presence  on  a  team.  This  process  is  created  to  fill  that 
communication  gap.  It  is  very  important  that  the  team 
own/develop  and  update  this  tool. 

Personal  Conflict  Resolution 

Personal  conflicts  within  the  team  is  one  of  the  most  disruptive 
elements  of  the  team  process.  They  cause  communication 
shutdown  and  team  polarization  resulting  in  loss  productivity.  It 
is  essential  that  conflicts  between  team  members  remain  within 
the  team.  Team  members  who  take  personal  conflicts  with 
other  team  members  to  persons  outside  the  team  should  be 
subject  to  disciplinary  measures  that  will  be  determined  by  the 
team  as  appropriate  to  the  occasion. 

Subteam  Assignment  Process 

In  order  to  improve  team  efficiency  a  process  must  be  in  place  to 
prevent  lengthy  discussions.  The  subteam  assignment  process 
appoints  a  subteam  (or  expert)  to  develop  a  strawmam  or  make 
a  decision  to  be  presented  to  the  team  for  buy-in. 

Action  Item  List  Process 
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The  action  item  process  identifies  new  tasks  that  are  not 
addressed  in  the  schedule.  These  new  additional  tasks  are  one 
of  the  primary  reasons  schedules  are  slipped.  The  action  item 
list  serves  three  purposes: 

It  tracks  the  status  of  the  new  items 
It  provides  a  simple  method  to  prioritize  new  tasks  and 
It  provides  the  basis  for  schedule  changes  or  requests  for 
additional  support  is  such  action  becomes  necessary. 

Internal  Approval  Process 

Throughout  each  of  the  design  phases,  team  members  who 
identify  improvements  to  the  current  process  or  design  must  be 
given  the  chance  to  present  their  ideas  to  the  team.  A  procedure 
for  internal  approval  to  allow  all  team  members  to  have  a 
chance  to  convey  their  thoughts  and  ideas  to  the  rest  of  the  team 
is  an  important  tool.  Using  this  tool  not  only  increases 
awareness  within  the  team  but  also  promotes  synergism  and 
helps  produce  a  better  process  and  product. 

Product  Design  Milestones  Identification  and  Change 
Procedure 

The  milestones  and  principal  dates  are  identified  in  order  to 
develop  the  project  schedule.  The  milestones  to  be  identified 
are  those  related  to  the  process  design  development  as  well  as 
those  related  to  the  product  design. 

The  milestones  and  principal  dates  initially  identified  may  have 
to  be  revised  due  to  issues  not  included  in  the  initial  schedule.  A 
task  to  be  included  in  the  schedule  is  “schedule  up-dating”, 
which  should  be  provided  at  regular  intervals. 

Owner/Operator  Participation  Procedures 

In  order  to  effectively  integrate  the  voice  of  the  customer 
through  the  design  process  it  is  recommended  to  have 
participation  from  an  owner/operator  in  the  form  of  a  chief 
engineer.  The  process  can  effectively  utilize  this  valuable 
resource  and  ensure  that  a  dynamic  partnership  is  created 
between  shipyard  and  customer. 

Process  and  Product  Metrics 

The  use  of  metrics  is  a  key  element  of  the  1PPD  process. 

Metrics  can  be  a  powerful  tool  to  improve  both  the  product  and 
a  team’s  social  behavior.  The  concept  of  process  and  product 
metrics  is  to  set  goals  and  use  an  in-process  measuring  system 
(metrics)  which  will  indicate  whether  the  goals  are  being 
approached  and  where  effort  must  be  focused  to  achieve  the 
project  objectives.  Metrics  are  essential  for  indicating  weak  and 
strong  points  in  both  the  design  process  and  in  the  final  product 
They  keep  the  design  team  and  management  in  touch  with  the 
original  concepts  of  the  project,  and  indicate  where  more  work 
is  needed  to  achieve  project  goals.  With  buy-in,  they  are  an 
agreed  upon  method  between  the  team  and  management  for 
measuring  project  success  in-process.  Post  process,  it  is 
ultimately  the  customer  that  measures  this  success. 

The  in-process  measurement  system  should  go  beyond  the 
traditional  methods  of  measurement  for  the  common  three  - 
Schedule,  Performance  and  Direct  Cost.  Therefore  the 


understanding  of  metrics  and  the  effect  of  such  on  both  process 
and  product,  along  with  the  conclusions  that  are  drawn  are 
difficult  to  agree  upon.  Especially  for  those  persons  outside  of 
the  team.  To  this  end  it  is  important  that  metrics  be  used  only  to 
show  direction  and  guide  a  team  towards  success. 

Cad  Subteam/System  Engineer  Interface  Process 

The  CAD  designers  and  the  CORE  Team  must  develop  a 
process  to  facilitate  the  exchange  of  information  between 
system  engineers  and  the  CAD  subteam.  This  process  should 
be  developed  to  reduce  confusion  between  team  members, 
eliminate  duplicated  information  being  submitted  to  the  CAD 
designers  and  to  document  the  information  being  transferred 
between  the  system  engineers  and  the  CAD  designers. 

Vendor  Information  Management  Procedure 

This  procedure  provides  a  method  by  which  Vendor  Furnished 
Information  (VF1)  is  requested,  received,  controlled  and 
reviewed  for  conformity  to  specific  project  requirements.  Each 
project  may  be  set  up  in  a  different  environment  and 
requirements  should  be  established  to  meet  the  shipowner 
needs.  Some  VF1  can  be  available  immediately  from  shipyard 
files  or  system  engineers.  Other  VFI.  shipowner  specific  vendor 
requirements,  may  be  very  difficult  to  obtain.  This  can  be  easily 
resolved  through  a  close  working  relationship  with  the 
customer.  Vendor  Furnished  Information  must  be  provided 
concurrently  with  the  engineering  work  during  Phase  1. 

Design  Review  Process 

The  design  reviews  shall  be  conducted  in  compliance  with  the 
IPPD  approach  of  in-process  review,  evaluation,  and  approval. 
The  design  reviews  shall  be  limited  to  the  current  phase  of  the 
project  that  is  being  addressed. 

The  goals  of  the  design  review  process  are  as  follows: 

•  Time  Phase  the  Buy-In  Process 

•  Promote  Concurrent  Incorporation  of  Comments 

•  Maximize  the  Development  of  the  Project  Final  Report 
Elements 

Ship  s  Systems  Integration  Process 

In  the  design  of  the  ship’s  systems  there  are  many  interface 
points  that  must  be  addressed.  The  identification  of  these  points 
of  interface  and  the  proper  integration  of  them  is  essential  to  the 
design  process. 

Information  Storage/Back-Up/Retrieval  Procedures 

All  enterprises  require  a  plan  for  managing  all  technical  and 
business  data  in  order  to  design,  build,  and  support  a  product 
through  its  life  cycle.  The  implementation  should  be  distributed 
in  order  to  take  full  advantage  of  the  networking  and  processing 
capabilities  of  the  enterprise  and  to  accommodate  the  possibility 
of  participating  within  a  virtual  enterprise.  Backups  should  be 
performed  on  a  daily  basis.  The  relational  database  used  to 
support  the  product  model  should  be  unloaded  nightly  to  text 
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files.  All  files  which  have  been  accessed  in  the  previous  days 
should  be  written  to  tape.  At  the  end  of  the  week  and  the 
month,  and  all  files  on  the  system  should  be  written  to  tape. 
Monthly  tapes  should  be  archived. 

Visit  Process 

Team  visits  to  ships,  vendors  and  related  facilities  to  gather 
information,  learn  operational  and  maintenance  characteristics 
of  various  equipment,  and  increase  the  shipboard  knowledge  of 
the  team  are  essential.  The  visit  process  is  created  to  increase  the 
effectiveness  and  document  the  results  of  the  visits. 

Capture  Lessons  Learned 

As  part  of  the  IPPD  design  process  there  is  a  need  to  capture 
any  lessons  learned  in  either  resolving  a  problem,  achieving  a 
goal  or  finding  a  short  cut  to  a  solution.  By  recording  the 
process,  team  members  can  refer  back  to  it  for  answers  or  to 
avoid  past  problems. 

User  s  Guide  Editing  Process 

The  ‘User’s  Guide'  is  the  product  of  the  process.  In  order  to 
improve  the  process,  the  process  itself  must  be  documented  and 
a  means  to  rapidly  incorporate  such  improvements  and 
disseminate  them  to  all  team  members  must  be  in  place.  This 
Guide  should  be  a  “living  document”  with  “continuous 
improvement”  of  the  document  occurring  as  lessons  are  learned. 
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